The “Payments by location” functionality allow for the system to record precisely to which organisation any charge raised by the system is owing to. In previous releases, charges were effectively considered as being owed to the system as a whole.
The use of this feature is completely optional for any implementation of Vubis Smart and is “turned on” by setting the appropriate parameters which determine the behaviour of the system.
In a consortium environment, the changes described below allow any specific charge raised within the system to be identifiably owned by a unique organisation. Optionally, the actual taking of payments for such charges may then be limited to users who are currently at a location relating to the relevant organisation.
Whether or not this option is used, the system records sufficient information to allow various reports to be made on payments received at locations other than the locations relating to the relevant organisations.
Note
The reader should note that certain parameter settings relate to parameters to allow payments to be made by credit and debit cards, using online secure links to external systems handling such details. See the credit card payments general help for more information.
So in summary the following points need to be taken into consideration:
· It is not mandatory to define financial groups
· It is possible to define financial groups without using electronic payment facilities
· In case the library uses electronic payment facilities, at least one financial group must be defined in order to be able to set the parameters for electronic payment
· It is not possible to define multiple financial groups that each have their own (electronic) payment options
Example
It is easiest to explain the concept of Payments by Location by considering an example. Suppose a borrower borrows a book from library Alpha, and returns it overdue with a resulting overdue fine at the same branch, without paying the fine.
Subsequently, the borrower goes to use branch Beta – several questions arise if he wishes to pay the fine outstanding, at that branch.
· Is it reasonable that branch Beta should take the money resulting from work carried out at branch Alpha?
· If so, should branch Beta actually keep the money or should it perhaps be given back to Alpha?
· If the book actually belonged to Beta in the first place, would that make a difference?
The answer is, of course: “it depends”. For example, on whether branches Alpha and Beta are part of the same administrative organisation, or on, in a more general way, on what the precise charge concerned was for – maybe membership charges are payable only to the branch at which the borrower joined, whilst overdue fines may be paid anywhere.
For many implementations of Vubis Smart, these questions are irrelevant. The settings below may be ignored within many implementations, and payments owing will be accepted at any location (within a circulation meta institution).
After staring AFO 497 the following menu will be displayed:
The various menu options will be discussed in the next paragraphs.
This section allows you to define two sets of parameters.
· For each type of charge that can be raised, this table allows you to define which possible location associated with the charge defines the location to which this charge is owed. For example, is a charge for a duplicate card owed to the borrower’s home branch or at the branch at which the charge was entered into the system.
· For each type of charge, you can define at which other locations such a charge is payable. For example, can I pay a charge owing to branch A at other branches which belong to the same institution?
Choosing this option results in a grid which displays each of the possible charge / payment types available within the system, as follows:
Lines may be neither added nor removed from the grid – since these represent all the possible charge/payment types potentially available. Although all possible charge types are displayed, for any one site some of these are not in use and you need only enter settings for those charge types which are relevant to you.
: Select a line and then this option to modify the charge location and/or payment option. After choosing this option the following form will be displayed:
Charge location: This setting defines the location to which the charge is considered to be payable. Possible values obviously depend on the specific nature of the charge concerned and the context in which it is raised. There are seven possible locations overall:
· the home location of the borrower
· the location of the transaction (e.g. where it was loaned)
· the owning location of an item
· the current management location of the item
· the location at which the item was returned
· the pickup location
· no specified location
Payment option: This setting defines at which locations the payment for a charge may be received, once the location “owning” the charge has been established. Valid settings are:
· Any - payment may be received at any location.
· Location - payment may be taken ONLY at the location to which the charge belongs (abbreviated as the “charge location” from here on).
· Institution - payment may be taken at any location which belongs to the same institution as the charge location.
· Financial group - payment make be taken at any location which belongs to the same financial group as the charge location.
Allow override: This check box allows a user to override these settings at runtime – in order to be able to accept any such payment type. Of course, this is irrelevant for the “Any” setting.
Notes
Reservations
For reservations charges created from the WebOpac, generally there is no location associated with the placing of the reservation, so no option for this is allowed.
Although the pickup location may be specified, in principle this may be (optionally) set to “pickup where found” – if this is selected, then the borrower’s home location will be used.
Since a reservation may be applied to many items across multiple locations, then of course, no specific item can be identified so only the borrower’s location and the transaction location are relevant (except see next paragraph).
Regardless of the above constraints, if the charge is actually created when a specific item is trapped, then item information is available and the system can allow for the item’s location to be a valid setting.
Miscellaneous
Miscellaneous charges never exist as such; the “miscellaneous” is actually just a payment, so much of this is irrelevant and it is only the location of the transaction (i.e. where the payment was accepted) which is valid.
Parameter applicability
These settings apply to the circulation meta institution as a whole.
The Charge location setting defines the location to which the charge is considered to be payable. Possible values obviously depend on the specific nature of the charge concerned and the context in which it is raised.
The following table shows the options which are valid for each type of charge.
|
Payment code |
Payment type |
Borrower home |
Item owner |
Item manager |
Item return |
Location of transaction |
Pickup Location |
|
A |
Membership |
Y |
|
|
|
|
|
|
B |
Fine |
Y |
Y |
Y |
Y |
Y |
|
|
D |
Duplicate card |
Y |
|
|
|
|
|
|
E |
Deposit incr/decr |
Y |
|
|
|
Y |
|
|
F |
Deposit refund |
Y |
|
|
|
Y |
|
|
I |
Enrolment |
Y |
|
|
|
|
|
|
K |
Article |
Y |
|
|
|
Y |
|
|
L |
Loan |
Y |
Y |
Y |
|
Y |
|
|
M |
Adm. costs |
Y |
|
|
|
Y |
|
|
P |
Postage |
Y |
|
|
|
Y |
|
|
Q |
Request |
Y |
Y |
Y |
|
Y |
|
|
S |
Staff placed reservation |
Y |
|
|
|
Y |
Y |
|
S |
Reservation from WebOpac |
Y |
|
|
|
|
Y |
|
S |
Reservation when charge created at collection |
Y |
Y |
Y |
|
Y |
Y |
|
V |
Compensation |
Y |
Y |
|
|
|
|
|
W |
Guarantee |
Y |
|
|
|
|
|
|
X |
Miscellaneous |
Y |
|
|
|
Y |
|
|
Y |
Service |
Y |
|
|
|
Y |
|
For an overdue fine, the “Location of the transaction” is the location at which the item was originally issued.
The consequences of setting these parameters are that the display in AFO 414 may be different, depending on the location you are looking at the details from. There may be additional options:
The above screen shows the most complex situation with regards to the Accept Payment screen.
In the example, we have
· a charge of 2.50 which is owed to the current location and is therefore payable;
· a charge of 2.00 which is owed elsewhere but for which an override is allowed;
· a charge of 22.50 which is never payable at the current location (no override allowed).
When you try to pay the charges, options are offered to allow you to select the override amount or not – for example:
This parameter allows for the definition of another grouping of locations which is independent of the institution associated with a location. For example, although branches A, B, C and D belong to the same organisation in general, for some charges A and B are independent of C and D. An example might be where A is the main library and B is the reference library, perhaps in the same building and sharing financial responsibilities, but which have been configured as separate locations (for some other functional reason within the system).
In addition, financial groups allow for locations to be grouped together for the purposes of access to the online credit card payment module - the philosophy and significance of this is explained within the credit card payments general help.
Financial groups are defined on a system wide basis – that is they may cut across any circulation meta institution boundaries. This allows for some complexities in the implementation of the online credit/debit card payment module. Of course, for any individual borrower, that borrower belongs to one meta institution for circulation only and therefore any charges visible only apply to a single meta institution.
Selection of the Financial groups option results in a standard grid listing such as:
In this example, we have a single main organisation and in addition we have a schools library service. Although these two organisations share a single circulation system, loan fees and overdue fines “belong” to the organisation at which the items were issued.
: select this option to add a new financial group. See section 497.3.1.
: select a code and then this option to modify the financial group.
: select a code and then this option to delete the financial group. The system will prompt for confirmation.
:select a code and then this option for the setup of additional parameters to be passed to an online payment broker (e.g. BucksNet), optionally, according to the language of the WebOpac or current client settings.
: select this option to add a new financial group. After choosing this option an input form will be displayed:
Financial group code: enter an appropriate code.
Description: enter a brief description for each language.
If electronic payment is activated, the input form will look like this:
Settings for BucksNet: The “Settings for BucksNet” are described elsewhere and need not be setup unless online credit card payment is required. See the credit card payments general help for more information.
Finally, it is necessary (if financial groups have been implemented) to link a location to a financial group. A simple setting tells the system to which financial group a location belongs.
After choosing this option an input form will be displayed:
The data input field is a combo box allowing either an blank entry or a financial group from the defined set of groups.
The two checkboxes allow the library to define for each location:
· If an option to pay by Credit card offered for paying membership fees from AF0431 will be offered.
· If an option to pay by credit card in AFO417 (Miscellaneous payments) will be offered.
This menu option allows a report to be run cross-referencing the locations at which a charge is paid against the location at which it was owed and is described later on.
The reconciliation report is designed to identify payments made at locations other than the location to which the charge was owed – in other words, it allows the library to determine that branch A, for example, took £212.50 which actually belongs to branch B.
The processing allows for a number of runtime options. Since it is expected that the report would be run at regular intervals, the standard ”Save Settings” option allows a regular “production” set of options to be setup once and used subsequently.
After choosing this option an input form will be displayed:
Name for this run: This field simply allows a “name” to be attached to the report for identification purposes.
Start date, End date: These two define the period for which payments are selected. In addition to a usual specific date, Start Date may be set to “Date of last run” where this is specific to the current user. End date may be set to “Today” or perhaps more usefully “Yesterday”. Thus for example, useful settings saved for these would be “Date of last run” and “Yesterday”.
Group by location: The location for a charge is defined at the Institution/Location level. Rather than breaking down the report for each location, the “group by” setting allows you to aggregate payments according to the location, institution or financial group.
(Thus, for example, we might simply report “Institution X owes institution Y a total of £345.23”, rather than “Location X/Alpha owes Location Y/Gamma £2.50, and Location X/Beta owes Location Y/Delta £4.87” and so on.).
Level of detail by date: Valid settings are “by day”, “by week”, “by month”, “by year”, “whole period”. Thus for example, if the report is “by day”, then a figure is given for each day in the period selected; whereas, for the whole period, a single figure is given.
Include figures where charge location equals payment location: This option allows you to include payments which were actually paid at the right location. In other words, you can report on all charges or just those for which the locations are different. In this case, the location means the location as defined by the “group by” setting. That is, if you group by institution then a charge paid at, say, “Avon County/Central” and “Avon County/West Branch” are considered to be the same location (whereas if grouping by Location, these would not)..
Note
Only one report per meta institution for circulation may be in process at any one time, and only one user may access this screen (per meta institution for circulation) at any one time.
The top lines show the most recent run – if it is in progress, then the “Completed line” will show “In progress”; or, if no report has been run, then the text “No previous reports” will be shown. Also shown are the last details for the current user, if these are different from the last overall run.
Clicking initiates the selection run. This brings up the regular ‘start process’ form.
Reports can therefore be run on a regular basis by setting the job as a permanent “in memory” process –although this probably only makes sense for a job for which the start and end dates are set to “Date of last run” and “Yesterday”.
When a report is completed, the “output results” command will output the results to a spreadsheet.
It should be noted that although an individual user’s date of last run and previous settings are saved on an individual basis, there is only one report current for any circulation meta institution; submitting a run will overwrite the results of a previous run.
Initially output will be only available as a .csv format file for importing into a spreadsheet.
Output fields are
· Charge Location
· Payment Location
· Charge period
· Charge type
· Payment type
· Payment type wording
· Total amount
Charge and payment location correspond to the “group by” setting (i.e. financial group, institution or location). Location will appear in the form XXX/YYY.
Charge period corresponds to the grouping. It will be in the form dd/mm/yyyy for by day, 2005.01 – 2005.53 if grouping by week, 2005.01-2005.12 if grouping by month.
Payment type will be the payment type code letter i.e. A – Y (as in the table in section 5.3.2); payment type wording is the “translation” of this code (in the current language of the user submitting the report).
Total amount will be the total paid amounts, totalled by the grouping period.
When the results are output, a spreadsheet will automatically open with the results – for example:
This can be used to generate the necessary reconciliation totals – for example, by using a Pivot Table we might get
showing that CEN owes BD 1.50, and BD owes CEN 1.25.
See the credit card payments general help for more information.
After choosing this option a submenu will be displayed:
The menu options will be discussed in the next paragraphs.
After choosing this option an input form will be displayed:
Credit card payments available: A check box, which can be used to turn the credit card payment options off or back on for the system as a whole.
Service provider: This is a combo box with one of the following options:
· None
· BucksNet
· iDEAL
Note
This is a SYSTEM wide setting. For the system as a whole only one payment service provider may be selected- if there are separate organisations (accounts) then they may have separate accounts BUT they must all use the same service provider. It would be possible to change from one service provider to another in the lifetime of the system (but would be for all users, and of course there are some practical considerations when a service provider is changed, not just for Vubis Smart).
The Payment system in use may be changed from “none” to one of the others but may NOT be changed once set (field will become inactive).
It can, if necessary, be reset by Infor support staff.
Once the payment system is set then the settings and options will vary in detail for each service provider (and of course the way that the system “talks” to the service provider).
Minimum amount: a limit below which payments by credit card are not allowed.
Charge: an optional additional fee for paying by credit card.
Typically a charge is levied for the use of credit cards against the organisation receiving the payment. Allowance for this can be made by specifying a minimum amount below which it is simply not worth using a card OR by adding an extra charge for credit card payments.
Total charges across groups to patron’s location: An option to allocate charges for more than one financial group to the group for the patron’s home location (see below). Currently this is ALWAYS set and the system behaviour in this regard may not be changed.
Full URL for successfully processed transactions: This is a CSP page for processing the transactions – for BucksNet the CSP page will be: “BNTransactionSuccessful.csp”. In other cases put in X (because the field is mandatory).
Full URL for failed transactions: Similarly for failed transactions, for BucksNet this must be: “BNTransactionFailed.csp”. In other cases put in X (because the field is mandatory).
(These names are case dependent on Unix based servers)
The main reason for these last two parameters is to identify the name of the service associated – in the above example, it is set to “HTTP://LOCALHOST/VSDEVWEB/” and would normally be the same as that for the WebOpac.
All these settings are shared for the whole system. It is not possible to adjust these settings for an individual organisation or institution within the system.
This option gives access to the reconciliation reports.
Since the reports are grouped according to the financial group associated, this function lists only the reports that are relevant to the financial group associated with the current user’s location. If the current location is not linked to a financial group then a message “No financial group has been defined for the current location” is displayed and the user is returned to the previous menu.
Entry to this function lists any reports visible in the destination directory for the associated financial group. This simple grid lists the report filenames and allows the reports to be printed.
In the event that something goes wrong between the time a user selects the Credit card payment” option and the actual payment (or failure), then the system will have recorded a transaction started but not completed.
The payment may or may not have gone through – and will be reported above.
In this event, the transaction must be “undone” – effectively as if the payment failed. If the payment DID go through (but the success of this never reached Vubis Smart) then the payment must be made manually in the online.
In the online, a payment “in progress” is reported by an indication (in brackets) of the service, date and time of the transaction. Of course, this may be displayed on a screen other than the one carrying out the payment, so it may be legitimate to see this.
In the even that there WAS a problem with the card transaction, then a staff member can only tell whether the transaction went through or not from the BucksNet reconciliation report, available the next day typically.
Using the information from the report, staff should use the “Repair Failed transactions” function to correct any such borrower data “in limbo”.
Finally since a card payment MAY cover more than one borrower’s charges, repairing the data for one borrower will cause the system to straighten out the charges for each borrower on the transaction. If this will happen, then a summary (names and barcodes) of the other borrowers will be displayed, for information.
Vubis Smart will allow the generation of a report in more or less the same format as that of the service provider, so that the two reports can be matched to cross check what Vubis Smart “thought” had happened with what is recorded on the service provider’s system.
After selecting this option an input form will be shown:
Fill in the required criteria and check which types of transactions you want to report on. After clicking , an overview screen will be presented:
This overview can then be compared to the report supplied by the service provider.
· Document control - Change History
|
Version |
Date |
Change description |
Author |
|
1.0 |
unknown |
creation |
|
|
2.0 |
December 2006 |
added examples of AFO 414 screens (delivered as part of release 2.4.2 build 1 updates) |
|
|
3.0 |
March 2007 |
updated doc hyperlink |
|
|
4.0 |
November 2007 |
revision of section on credit card payments delivered as part of 2.4.2.4 updates |
|